IP security protocols are widely used to protect packets communicated between endpoints (EPs), such as over the Internet, between gateways, between data centers (e.g., on premises data centers, cloud data centers, etc.), within data centers, etc. For example, security associations (SAs) may be established between the endpoints. In some embodiments, each security association is a one-way or simplex connection, and therefore at least two security associations, one for each direction, are established between two IPsec peers (e.g., endpoints). These security associations are a form of contract between the endpoints detailing how to exchange and protect information among each other. In some embodiments, each security association is comprised of a mutually agreed-upon key, one or more security protocols, and/or a security parameter index (SPI) value. After security associations have been established between two endpoints, an IPsec protocol may be used to protect data packets for transmission.
For IPsec in the Encapsulating Security Payload (ESP) tunnel mode, tunnel endpoints are used for applying IPsec protocols to encrypt and encapsulate egress packets from a source endpoint and decrypt and decapsulate ingress packets for a destination endpoint to secure communication between the endpoints. For example, a source endpoint may generate and route egress IP packets to a source tunnel endpoint associated with the source endpoint. In particular, the source endpoint may generate an IP packet including a header with the IP address of the source endpoint set as the source IP address and the IP address of the destination endpoint set as the destination IP address. A MAC address of the source tunnel endpoint may further be set as a next-hop MAC address of the IP packet in the header.
The source tunnel endpoint receives the IP packet and encrypts the original IP packet including the header of the original IP packet based on a security association established between the source tunnel endpoint and the destination tunnel endpoint. For example, the source tunnel endpoint encrypts the original IP packet with a mutually agreed-upon key of the security association. The source tunnel endpoint further encapsulates the encrypted packet by adding a new IP header and an ESP header (e.g., including an SPI value corresponding to the security association used to encrypt the packet) to the encrypted packet to generate an encapsulated ESP encrypted data packet. The new IP header includes a source IP address of the source tunnel endpoint and a destination IP address of the destination tunnel endpoint. The new IP header is used to forward the encapsulated ESP encrypted data packet through a network from the source tunnel endpoint to the destination tunnel endpoint.
The destination tunnel endpoint may then decapsulate and decrypt the encapsulated ESP encrypted data packet to extract the original IP packet. For example, the destination tunnel endpoint may determine the security association (e.g., mutually agreed-upon key) to use to decrypt the encapsulated ESP encrypted data packet based on the SPI value included in the ESP header. Based on the destination IP address in the header of the original IP packet, the destination tunnel endpoint forwards the original IP packet to the destination endpoint.
IPsec protocols may be deployed in virtualized computing instances (e.g., a virtual machine (VM) or container) to gain the benefits of virtualization and network functions virtualization (NFV). For example, virtual computing instances may be configured to serve as tunnel endpoints as described. However, use of such IPsec protocols by virtualized computing instances may cause certain other features at the virtualized computing instances to function improperly.
In a virtualized environment, virtual network interface controllers (VNICs) are instantiated in a virtualization layer (also referred to herein as the “hypervisor”) supporting such virtualized computing instances and are programmed to behave similarly to physical NICs (PNICs). One feature both PNICs and VNICs have supported is receive side scaling (RSS), which involves computing a hash of incoming packet header attributes and distributing the incoming network traffic across CPUs for processing based on the computed hash values. Packets belonging to the same connection are distributed to the same RSS queue, based on the computed hash value, for processing by a particular CPU. For a VNIC, packets are distributed to virtual RSS queues associated with the VNIC based on the computed hash value. The packets in a virtual RSS queue are processed by a particular virtual CPU associated with the virtual RSS queue.
Traditionally, for a VNIC, RSS is performed for IP packets based on a detected packet type indicated by an IP protocol number in an IP header of the packet that indicates the next higher layer protocol being carried as the IP payload. For example, the VNIC may be configured to perform RSS only for packets of type ICMP, UDP, and TCP, corresponding to IP protocol numbers 1, 6, and 17, respectively. However, for packets encapsulated using ESP tunnel mode, the IP protocol number in the new IP header may be 50. Accordingly, the VNIC may not be configured to perform RSS for received encapsulated ESP encrypted data packets.
Further, the hash computed for selecting a RSS queue is traditionally computed based on the source IP address and destination IP address in the header of the packet. In an encapsulated ESP encrypted data packet, the only available (i.e., non-encrypted) IP addresses for computing the hash are the source IP address of the source tunnel endpoint and the destination IP address of the destination tunnel endpoint. Accordingly, at a VNIC of a destination tunnel endpoint, all encapsulated ESP encrypted data packets received from the same source tunnel endpoint, regardless of the source endpoint that sent the packet and the destination endpoint, would have the same source IP address and destination IP address in the new IP header, and therefore hash to the same value and be assigned to the same virtual RSS queue. Therefore, RSS could not be used to distribute processing of such encapsulated ESP encrypted data packets amongst multiple virtual RSS queues and accordingly multiple virtual CPUs.
In some cases, VNICs may be configured to perform RSS for received encapsulated ESP encrypted data packets. For example, the destination tunnel endpoint's VNIC may be configured to compute a hash of incoming packet header attributes, including an SPI value associated with each packet, and distribute the incoming network traffic across CPUs for processing based on the computed hash values. However, even in such cases, unless there is a very large number (e.g., thousands) of IPSec tunnels (e.g., such that there are many different combinations of source and destination tunnel endpoint IP addresses) or many different security associations (e.g., such that there are many different SPI values, in cases where there is a single IPSec tunnel), it is very unlikely that the RSS performed by the VNIC results in a statistically uniform distribution of packets to virtual CPUs.